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INTERNET BARGAINING SYSTEM 

BACKGROUND OF THE INVENTION 

1. Field Of The Invention 

The present invention relates to electronic commerce applications that utilize 
digital and analog networks; and, more particularly, to a method and system for 
conducting electronic commerce over the Internet. 

2. Description Of The Prior Art 

Computerized marketplaces are enjoying widespread use. These marketplaces 
have been successfully run domestically and in many foreign countries. 
Computerized markets range from simple classified ad, bulletin boards to complex 
mainframe-based market systems, such as NASDAQ, which provides a real-time 
market-making system for tens of thousands of securities brokers. Modern stock, 
bond and commodity exchanges are supported by computerized databases and 
related background systems that enable them to function. 

Typically, electronic Exchanges are designed to facilitate commercial 
transactions involving tokens of ownership, such as shares of stock or physical 
objects such as cars, gold and the like. Other Exchanges specialize in the sale of 
information stored on databases that require payment of access fees to content 
providers for proscribed content downloaded by the user. Still other Exchanges 



provide matching services for parties seeking an efficient way to find each other. An 
example of matching services provided by an Exchange of this kind are the services 
afforded by a dating service or a job bank. 

Exchanges can also function to support a market place for the buying and 
selling of consulting services. These types of Exchanges support a form of activity 
that is appointed to take place in the future. The Exchange serves as a structured 
meeting ground for the negotiation of the service to be provided. During operation 
of these types of systems, both parties must disclose their identities to each other. 
When trading is imminent, one party simply contacts the other directly and privately, 
without the Exchange's knowledge, thereby avoiding any costs, which might 
otherwise have been assessed by the Exchange. 

Working expert exchange marketplaces, whether they are physical or 
electronic, require a complete and highly specialized set of conditions in order to 
function and thrive. Certain ingredients or features of service, if missing, can result 
in a shortage of either buyer or seller or lead to the collapse of the Exchange. 
Sufficient qualification of each is clearly needed for continued operation. At the 
same time, the Exchange must be able to ensure that income derived from the 
commerce of its activities is sufficient to cover operating costs and sustain 
profitability. 

Exchanges should also provide sufficient motivation to ensure that significant 
numbers of buyers and sellers use the exchange in lieu of other available market 
place alternatives. Several factors, if present, would motivate buyers and sellers to 
use an exchange: (i) there must exist a high expectation of the usefulness of the 



Exchange that makes the user willing to take the time and effort to learn the rules of 
the exchange; (ii) buyers and sellers should be able to locate each other on the 
exchange at exactly the right time and place; (iii) a buyer and a seller should be able 
to quickly and easily negotiate transaction terms; (iv) buyers and sellers must reach 
a complete and final agreement in which the expectations of the parities are well 
defined; (v) there must exist an arrangement for acceptable credit terms; (vi) a 
mechanism should be provided for delivery of the goods or services called for by the 
agreement; (vii) there must exist a mechanism to deliver payment when the 
agreement is fulfilled; (viii) buyers and sellers must be able to rely on the Exchange 
to enforce agreements made on the Exchange with certainty of payment and legal 
recourse; transaction fees must be reasonable in comparison to alternatives; buyers 
and sellers should enjoy ready access to the market without levels of knowledge and 
cost of hardware commensurate with the value of the goods or services sold on the 
Exchange. 

Traditional real world commerce in expertise or consulting services strongly 
favors circumstances where both parties are in the same place at the same time and 
can see one another. When there is no face-to-face contact and the parties instead 
rely on mail, phone, faxes etc., significant burdens and costs are imposed. These 
burdens and costs reduce the likelihood that expert commerce will take place. This is 
especially true if the parties are located in countries with different languages, 
customs, legal systems, currencies etc. Each added burden dramatically reduces the 
chances for agreement and makes it more difficult to satisfy all of the previously 
noted infrastructure conditions. If one or both of the parties in an online transaction 



is a private-party with no established organization or commercial resources, the 
difficulties heretofore discussed tend to increase. 

Notwithstanding the problems faced in this field, the twenty-first century 
demand for worldwide commerce and Exchange services is expected to increase 
5 dramatically. A myriad of businessmen, government officials, academics and 

ordinary consumers now interact with each other via online networks. Consequently, 
the demand for worldwide commerce and Exchange services is growing dramatically. 

- To exploit this potential growth, there is needed a universally accessible 

facilitating system. Such a system should be especially designed to process the 

10 purchase and sale of goods and services in an effective, smartly structured manner. It 

must be thorough and„ cover aspects of an arms-length bargain not present when 
goods and services are electronically purchased or sold in the conventional way. 

Computerized stock markets seamlessly and effortlessly process transactions 
of billions of shares of equities, bonds and financial instruments every day. In like 
15 manner, there exists a need for a mechanism that facilitates purchase and sale of 

goods at an optimum price. Especially needed is a system wherein the buyer and 
seller need not see or meet each other; but can deal effectively through use of a 
structured, organized system that facilitates and supports the infrastructure needed 
for commercial transactions involving purchase and sale of goods. 



20 



SUMMARY OF THE INVENTION 

The present invention provides an electronic bargaining system that: 
(i) enables buyers to bargain with the system in order to negotiate an optimum 
bargain price; and (ii) enables sellers to sell or list their products by bargaining with 
the system to negotiate the best offered price. Advantageously, the system permits 
purchase and sale of goods to be transacted at a bargained for price that represents 
the best bargain obtained by the parties. That is to say, a bargained for price for 
transactions consummated by the electronic bargaining system is reached by the 
parties in a highly reliable manner. Principal attributes of that bargained for price are 
those captured by the characterization: "Our Best Bargain, Your Best Bargain". 
Generally stated, the system apparatus comprises: 

(i) a Business Controller unit adapted to process buyer requests and to 
initiate a bargain process structured to provide an optimum price for each of the 
buyer and the system, the Business Controller unit being further adapted to process 
seller requests and to initiate a bargain process structured to provide an optimum 
price offered to the seller by the system, said controller unit being connected with a 
database unit that searches the database to generate a search result, and processes the 
search results according to the buyer and seller request; 

1. a database controller unit having all required databases such as payment 
database, billing database, buyer database, seller database, and product database; 
and 
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(iii) a transceiver disposed in communication with the Business Controller 
unit, for transmitting Business Controller generated responses to buyers and the 
sellers and receiving buyer and seller requests to initiate a bargain process. 



5 BRIEF DESCRIPTION OF DRAWINGS 

The invention will be more fully understood and further advantages will become 
apparent when reference is had to the following detailed description and the accompanying 
drawings, in which: 

FIG. 1 is a block diagram illustrating the functional components of the present 
10 Internet bargaining system, including Business Controller 2.0, database controller 3.0, buyer 
interface 5.0, and seller interface 6.0; 

FIG. 2 is a block diagram illustrating the functional components of Business 
Controller 2.0; 

FIG. 3 is a block diagram illustrating the functional components of database 
15 controller 3.0; 

FIG. 4 is a block diagram illustrating the functional components of the network 
interface 4.1; 

FIG. 5 is a block diagram illustrating the functional components of the buyer 
interface 5.0; 

20 FIG. 6 is a block diagram illustrating the functional components of the seller 

interface 6.0; 

FIG. BF1 is a flowchart illustrating a process by which buyer formulates buyer 
request 1.2; 
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FIG. BF2 is a flowchart illustrating a process wherein the initial processing of buyer 
request 1.2 and first response generation by Business Controller 2.0 is intentional; 

FIG. BF3 is a flowchart illustrating an alternate process for buyer request 
processing; 

5 FIG. BF4 is a flowchart illustrating a process for offline bargaining in which 

Business Controller 2.0 bargains with more than one buyer; 

FIG. BF5 is a flowchart illustrating a bargain price generation process by Business 
Controller 2.0 during bargain negotiations with buyer; 

FIG. SF1 is a flowchart illustrating a method wherein the seller registers himself 
1 0 with the Business Controller 2 .0 ; 

FIG. SF2 is a block diagram illustrating a process by which the seller submits 
product details; 

FIG. SF3 is a flowchart illustrating a process by which Business Controller 2.0 
performs the creation and initial processing of the seller request 1.4; 
15 FIG. SF4 is a flowchart illustrating a process wherein the seller wishes to sell a 

product to Business Controller 2.0, or the seller wishes Business Controller 2.0 to place 
seller's product on sale; 

FIG. SF5 is a block diagram illustrating the inquiry process used by the seller to 
inquire about the sale of a product; 
20 FIG. BN1 is a block diagram illustrating a process by which buyer creates a profile 

and registers with the system online; 

FIG. BN2 is a block diagram illustrating a process by which the buyer selects a 
product and creates a buyer request; 
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FIG. BN3 is a flowchart illustrating a process used by buyer to make his request to 
Business Controller 2.0 after selecting the product online, and a process by way of which 
Business Controller 2.0 initiates the bargain process; 

FIG. BN4 is a flow chart illustrating the initial processing of buyer request 1.2 and 
5 first response generation by Business Controller 2.0; 

FIG. BN5 is a flow chart illustrating the process of online bargaining between buyer 
and Business Controller 2.0; 

FIG. BN6 is a flow chart illustrating a process of online bargaining in which 
Business Controller 2.0 bargains with more than one buyer; 
;10 FIG. BN7 is a flow chart illustrating a process wherein a continuous 

communications channel is established between the buyer and Business Controller 2.0 using 
a message window; 

FIG. SN1 is a flow chart illustrating a method by which the seller registers himself 
with Business Controller 2.0; 
1 5 FIG. SN2 is a flow chart illustrating a method by which the seller registers himself 

with Business Controller 2.0; 

FIG. SN3 is a flow chart illustrating a process in which Business Controller 2.0 does 
the initial processing of the seller request 1 .4; 

FIG. SN4 is a flow chart illustrating the transactions involved when the seller wishes 
20 his product to be opened for sale; 

FIG. SN5 is a flow chart illustrating the process by which the seller bargains with 
Business Controller 2.0 to get the best bargain price for the product, sells it to Business 
Controller 2.0 at step SN5.1, and provides the ID number for authorization at step SN5.2; 
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FIG. SN6 is a block diagram illustrating an embodiment in which the seller can 
inquire about the sale status of the product; 

FIG. BB1 is a flowchart illustrating a bidding process in which the buyer bids for a 
product; 

5 FIG. BB2 is a flowchart illustrating a method for processing a request created by the 

buyer; 

FIG. BB3 is a flowchart illustrating an alternate form of bidding procedure; 
FIG. BP1 is a block diagram depicting an embodiment of the billing and payment 
system in which the billing process is initiated; 
1 0 FIG. BP2 is a block diagram depicting a process for paying the seller or vendor; 

FIG. BP3 is a block diagram depicting a billing procedure using credit cards as a 
primary transaction tool; 

FIG. BP4 is a block diagram depicting a billing procedure utilized when the amount 
to be paid to the seller has been calculated; 
1 5 FIG. BP5 is a block diagram illustrating a payment procedure for billing buyer using 

standard bank checks; 

FIG. BP6 is a block diagram illustrating a payment procedure for transmitting 
payment to seller involving standard bank checks; 

FIG. BP7 is a block diagram illustrating a procedure in which funds are transferred 
20 via "EFT"; 

FIG. BP8 is a block diagram illustrating a procedure in which funds are transferred 
to the seller via "EFT"; 

FIG. BP9 is a block diagram depicting a procedure for billing the buyer using digital 

cash; 
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FIG. BP10 is a block diagram depicting a process for sending payment to the seller 
using digital cash; 

FIG. CS1 is a flowchart illustrating a customer satisfaction embodiment, the 
elements of which include buyer complaint reviewing and follow-up procedures; and 
5 FIG. CS2 is a flowchart illustrating the handling and processing of comments 

concerning the quality of products received by the buyer. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The term "bargaining" as used herein means a process used by two or more parties to 
10 arrive at an agreement, which governs certain rights and duties between them. During the 
- bargaining process, the negotiating parties give reasoning and incentives to convince the 

other party to come to terms. This whole process is referred to herein as bargaining. The end 

result is an agreement on which the parties execute accordingly. 

I Advantageously, the Internet bargaining system of the present invention affords new 

15 features and value-added services to the customers that have not heretofore been available. 
It fulfills a longstanding need for a buyer-driven bargaining system that enables the buyer to 
bargain for the price he wants. In addition, the system provides a seller-driven bargaining 
system that avoids sellers concerns about publicity and price of their product. That is to say, 
the system provides a unique Internet bargaining structure that proceeds on the basis of "our 
20 bargain price, your bargain price". 

In general, the Internet bargaining system provides the following services and 
features for the buyers and sellers. 
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The buyer is able to find bargains at a price most suitable to him. In use of the 
Internet bargaining system described above, it is unnecessary for the buyer or seller to see or 
meet each other. The system provides substantially all information about the product, and 
questions concerning the product are addressed. Buyers can contact the system at a 
5 convenient time using a variety of communication modes. Preferably a buyer uses a 
communication mode selected from the group consisting of on-line, off-line and real-time. 
Each of these communication modes will be described hereinafter in further detail. At the 
request of the Buyer, the system can provide assistance via prompts, pop-up messages and 

: i icons, thereby enabling Buyer to proceed with the bargaining process on his own. 

- 1 0 Assistance from a system consultant is also provided, upon Buyer request. 

Sellers obtain a negotiated and best available price for their products. Substantially 
all bargains are negotiated by the buyers to obtain an optimum price for seller goods or 
w services. In one embodiment, the system processes all the financial matters of the deal for the 
buyer and the seller. Sellers do not have to engage in the troublesome task of bargaining 
15 with single or multiple buyers. The system operates as an optimized and expert middleman 
between the buyer and the seller. Transactions can be negotiated and consummated on a real 
time basis or offline, on the basis of bargained for, mutually agreeable terms. 

These features, in combination, provide an Internet bargaining system that is easy to 
use and enables bargaining to be carried out and bargains reached in an effective, cost 
20 efficient manner. 

Referring to Figs. 1-6 of the drawings, there is shown the method and apparatus of the 
present invention. In a preferred structure the system of the invention comprises: buyer 
interface 5.0, database controller 3.0 and an associated database. The system identifies the 
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appropriate mode of bargain, supervises the bargain requests by the user, and processes 
those requests to produce appropriate bargain responses. Advantageously, in operation of 
the system, the buyer and seller can arrive at a suitable bargain price in a simple cost and 
time effective manner. The term "user" is herein intended to mean a buyer or seller that 
accesses the system to participate in a bargaining process, bench mark a product or service, 
or otherwise obtain information concerning products or services offered by the system. 

The system architecture for the preferred structure of the present Internet bargaining 
system is illustrated in Figs. 2,3,5, and 6. Referring again to Fig. 1, the apparatus comprises 
Business Controller 2.0, database controller 3.0, buyer interface 5.0, seller interface 6.0, 
(collectively, the " nodes "). Each node is connected via an Internet connection using a 
public switched phone network 1.1, such as those provided by a local or regional telephone 
operating company. Connection can also be provided by dedicated Data lines, cellular 
phones, 'Tersonal communication system (PCS)", wireless computer and hand-held devices, 
and microwave or satellite networks. Buyer interface 5.0 and seller interface 6.0 are used 
both as inputs and as output gateways for communications with Business Controller 2.0. 

The method and apparatus of the invention utilizes these components to implement a 
unique bargaining system in which buyers and sellers can interact with a Business Controller 
2.0 assigned expert to arrive at a price that optimally suits their demands. The assigned 
expert can comprise a system generated assistant, referred to herein as a "Bargain Guru". It 
can also comprise a consultant, available on an on-line or off-line basis, to provide 
assistance or otherwise facilitate the bargaining process. 

As illustrated by Fig. 2 of the drawings, Business Controller 2.0 includes central 
processor (CPU) 2.4, encoding/ Decoding process 2.1, payment processor 2.6, Bargain 
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formulation processor 2.5, Commission formulation processor 2.7, Business rules 
component 2.8, Operating system 2.2, and network interface 3.1. A conventional personal 
computer or workstation with sufficient memory and processing capability may be used as 
Business Controller 2.0. Alternatively, the Business Controller 2.0 can comprise a hand held 
5 wireless communication device such as a Palm Pilot®, WordPad® or the like. 

In one embodiment, Business Controller 2.0 operates as a Web server, both receiving 
and transmitting data inquiries generated by buyers and sellers. Business Controller 2.0 must 
be capable of processing high volume transaction, performing a significant number of 
: mathematical calculations in processing communications. A Pentium-E 300 MHz 
30 microprocessor commonly manufactured by Intel Inc. may be used for CPU 2.4. This 
\ processor employs a 32-bit architecture. Other processors suitable for use as CPU 2.4 
I include Motorola 120MHZ PowerPC or Sun Microsystems SOLARIS. 

?. Each of billing processor 2.3 and payment processor 2.6 can comprise a 

conventional microprocessor (such as Intel Pentium) supporting the transfer and exchange of 
15 payments, charges, or debits attending transactions processed. These processors may also be 
configured as part of CPU 2.4. 

Processing of credit card transactions may be supported with commercially available 
software, such as the Secure Web server manufactured by Open Market Inc. This server 
software transmits credit card numbers electronically to the Open Market headquarters for 
20 card-processing verification. An Integrated Commerce Service at the Open Markert 
headquarters provides back-office services necessary to run Web-based businesses. The 
back-office services include online account statements, order-taking and credit card payment 
authorization, credit card settlement, automated sales tax calculations, digital receipt 
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generation, and account based purchase tracking and payment aggregation for low priced 
services. 

The bargain formulation processor 2.5 and the commission calculation processor 2.7 
can comprise conventional microprocessors (such as Intel Pentium) that support 
5 mathematical processing of different bargain prices and calculation of commissions. A 
business rules component 2.8 can use this type of microprocessor for its functionality. 

A database controller 3.0, shown in Fig. 3, comprises a conventional personal 
computer or computer workstation having sufficient memory and processing capability. In 
- one embodiment, database controller 3.0 operates as a Database Server, both receiving and 
-4 0 transmitting data inquiries generated by the Business Controller 2.0 . 

Fulfilling the high volume transaction processing and data queries required during 
: operation of the Internet bargaining system requires a powerful microprocessor. A Pentium 
II 300 MHz microprocessor commonly manufactured by Intel Inc. can comprise CPU 3.1. 
Other equivalent microprocessors may also be used. 

15 A data storage device of the type suitable for use with the invention generally 

includes magnetic storage devices such as fixed discs, and the like. These storage devices 
will be used for housing the databases used in the processing of transactions by the system. 
These databases include buyer database 3.5, seller database 3.6, product database 3.9, 
request database 3.3, response database 3.4, payment database 3.7, billing database 3.8, and 

20 audit database 3.10. In a preferred embodiment database software such as Oracle 8, 
manufactured by Oracle Corporation, is used to create and manage these databases. 
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Buyer database 3.5 maintains data on each buyer, including name, address, phone, E- 
mail, payment preference, language preference, product preference and the like. Seller 
database 3.6 maintains data on each seller such as name, address, phone, E-mail, language 
preference, past selling record, product ID, price range preference for sale of the product 
5 either as a single item or in bulk, or as a package deal, availability of the product, condition 
of the product, picture, if available, and the like. In addition, seller database 3.6 contains 
information about the product ID, and any advertising data of the product to be sold. The 
seller database 3.6 also holds information about bargain bids and the response generation by 
}c the system. 

10 The Bargain request database 3.3 includes all buyer requests 1.2 received by 

; 1 Business Controller 2.0, indexed by product ID. A unique tracking number is also stored for 
z : each buyer request 3.3. 

I The bargain response database 3.4 contains all bargain responses issued by Business 

> Controller 2.0. This database is indexed by the request tracking number. Bargain response 
15 database 3.4 also contains all the bargain prices issued by the Business Controller 2.0 in the 
bargaining process of a product. 

Payment database 3.7 and billing database 3.8 track all commercial transactions, as 
well as payment and billing preferences and, optionally, shipping details and product 
tracking information. These databases are valuable in the event of inquiries by both buyer 
20 and seller so that an audit trail can be produced. Product database 3.9 maintains product ID 
and other details about the product. 
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Audit database 3.10 stores transactional information that may be retrieved for later 
analysis; for example, the buyers and sellers negotiations proceedings from chat rooms, or 
audit trails by the Business Controller 2.0 might be stored in this database so that buyer or 
seller inquiries concerning service or price, or the transaction history can be independently 
verified. 

Network interface 4.1 provides a gateway for communication with buyers and sellers 
through a buyer interface and a seller interface, respectively. Conventional internal or 
external modems serve to provide the network interface. The modem is supported at a baud 
rate ranging from 28800 upwards, but may combine such inputs into a tl or t3 line, if more 
bandwidth is required. 

In a preferred embodiment, network interface 4.1 is connected with the Internet 
and/or any of the commercial Internet service providers, such as AOL, CompuServe, IBM, 
and the like. This allows both buyers and sellers to access the system from a wide range of 
online connections. As used herein, the term "connection" means a conventional wired 
connection as would be provided by a modem and telephone line or, alternatively, a wireless 
connection, such as that provided by a wireless modem, cell phone or the like. Several 
commercial e-mail servers include the above functionality. Outlook Express, an electronic 
mail software package manufactured by Microsoft Corporation, is designed to link people 
and information over enterprise networks and the Internet. Any other plat-independent e- 
mail, secure server-based software that uses open standards based on Internet protocols can 
be used. Buyers and sellers can exchange messages with files, graphics, video and audio. 
The system should support multiple languages. 
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Although the foregoing embodiment describes a single computer acting as the 
Business Controller, it will be readily appreciated by those skilled in the art that the 
functionality can be distributed over a plurality of computers. In another embodiment the 
Business Controller 2.0 and the database controller 3.0 are configured in a distributed 
5 architecture, shown by Fig. 4, wherein the database and processor components are housed in 
separate units or locations. Business Controller 2.0 components perform the primary 
processing functions and contain at a minimum RAM, ROM and a general processor. Each 
of these controllers is attached to WAN HUB 4.2 that serves as the primary communication 

: : link with the other devices WAN hub 4.2 may have minimal processing capability itself, 

!i 0 serving primarily as a communications router. 

Although a limited number of controllers are shown in this embodiment those skilled 
in the art will appreciate that an almost unlimited number of controllers may be supported. In 
\- such configuration, each controller is in communication with its constituent port, but stand- 
- alone units perform the processor and/or data storage functions. 

15 Payment processor and database 4.3, billing processor and database 4.4, and 

buyer/seller database 4.6 communicate through WAN Hub 4.2 with controllers 4.7 through 
4.9. With this arrangement, the system is more flexible and dynamic, and less vulnerable to 
catastrophic hardware failures. 

In Figs. 5 and 6 there is illustrated a buyer interface and a seller interface, 
20 respectively. Typically, each of these interfaces is provided by a personal computer having 
an input device such as keyboard, mouse, or conventional voice recognition software 
package. Each of the buyer and seller interfaces also has a display device such as a video 
monitor, a processing device such as a CPU, and a network interface such as a combination 
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of modem and an ISP connection. Alternatively, the buyer interface 5.0 and seller interface 
6.0 may also be voice mail system, or other electronic or voice communication system. 
Devices such as fax machines or pagers are also suitable interfaces. Buyer and seller 
interfaces other than on-line via the Internet will be managed through the phone system and 
the bargaining process will be facilitated by customer service agents. 

Referring to Figure 5, the buyer interface is described which includes central 
processor (CPU) 5.1, RAM 5.2, ROM 5.3, video driver 5.8, video monitor 5.10, 
communications port 5.7, input device 5.9, network interface 4.1 and a data storage device. 
Each of these components is substantially identical to those described in Fig. 6. 

The primary functions of the seller interface 6.0 and the buyer interface 5.0 are 
message creation and transmission. Numerous commercial software applications can enable 
the communications required by seller interface 6.0 and buyer interface 5.0. MS Outlook 
Express, manufactured by Microsoft, for example, provides editing tools for the creation of 
messages as well as communication tools to route the message to the appropriate electronic 
address. 

Referring to Fig. 6 there is shown seller interface 6.0. The seller interface includes 
central processor (CPU) 6.1, RAM 6.2, ROM 6.3, video driver 6.8, video monitor 6.10, 
communication port 6.5, input device 6.9, network interface 4.1, and data storage device 6.6. 
CPU 6.1 can be comprised of a Pentium microprocessor such as 100 MHz P54C. CPU 6.1 
has a standard chip-based clock, which is used to timestamp the seller request produced with 
seller interface 6.0. A modem is required to transmit data to Business Controller 2.0 for 
further processing so that the seller's product may be advertised open for bargain and given 
a starting bargain price. The encoding and decoding processor 6.4 is required to encode and 
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decode data transferred to and from Business Controller 2.0. Data and decoding processor 
will be discussed at a later stage. Data storage device 6.6 is a conventional magnetic based 
hard disk storage unit, such as those manufactured by Western Digital. Information database 
6.6 is used for archiving seller requests and the bargain details, payment records and 
5 shipping details are recorded at local database 6.7. 

Asynchronous Bargaining Embodiment 

In one embodiment of the current invention, the communication between buyers and 
the sellers takes place asynchronously through Business Controller 2.0. The buyer creates 

10 buyer request 1.2, transmits it to the Business Controller 2.0 and then disconnects from the 
network. The Business Controller 2.0 generates a buyer response 1.3, accepting the request. 
In the event that the buyer request is not acceptable, the Business Controller 2.0 generates a 
new bargain price for the buyer and sends it to the buyer for consideration. The buyer then 
generates a new buyer request based on the new bargain price received from Business 

15 Controller 2.0. This process is continued until (i) an acceptable price is arrived at, or (ii) one 
of the parties to the transaction discontinues the bargaining process, or (iii) the product or 
service becomes unavailable, or (iv) buyer runs out of chances or does not request additional 
chances, or (v) the predetermined time period allotted for bargaining has expired. 

Alternatively in the case of seller, the seller sends a seller request containing a 
20 seller's offered price and details about his product to the Business Controller 2.0 and 
disconnects from the network. Business Controller 2.0 then generates a response having the 
form of (i) disapproval of seller's request or (ii) request for more details, or (iii) acceptance 
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of the seller request, or (iv) provisional acceptance of seller request based on a modified 
bargain price or modified product or service offering suggested by the Business Controller 
2.0. In the event that the seller request is not accepted by the Business Controller 2.0, the 
seller generates a seller request based on the response received from Business Controller 2.0. 
This process is continued until (i) an acceptable seller request is arrived at, or (ii) one of the 
parties to the transaction discontinues the bargaining process, or (iii) the seller decides to list 
the product on open sale, as described herein, or (iv) the seller runs out of chances or 
declines to purchase additional bargaining chances, or (v) the predetermined time for 
bargaining has expired. In either case the buyer or seller does not communicate with the 
Business Controller in real time. 

Offline Communications with Buyer 

With reference to Figure BF1, there is described the process by which buyer 
formulates buyer request 1.2. 

The buyer first creates a request at step BF1.1, by choosing a product from the given 
list of (i) products, which include airline tickets, new and used cars, electronic components, 
computer peripherals, groceries, furniture, antiques, and the like; and/or (ii) services, which 
include legal services, consulting services, babysitting services, maid services, medical 
services, and the like. It will be appreciated by those skilled in the art that the list of 
products and services includes a myriad of products and services, that is to say, virtually any 
product or service which is required by a consumer or business entity and can be readily 
valued and priced for sale, and which is susceptible for purchase and sale in a bargaining 
context. The term "product", as used herein is intended to include any product and/or service 
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that constitutes subject matter adapted to be priced and sold for a bargained for 
consideration. 

The buyer attaches his ID number to the request at step BF1.2. This ID number is 
received from the Business Controller 2.0 when buyer registers for the service and submits 
his profile (as illustrated below in figure BN1). 

Business Controller 2.0 maintains a database of buyer ID numbers in buyer database 
3.5, and issues or allows only unique numbers. At step BF1.3, the buyer attaches criteria to 
request as shown in step BF1.35 in the figure. Criteria typically includes the type, size, time, 
model, make, model number, and the like. 

At step BF1.4, both the buyer ID and criteria are combined with request, producing a 
complete buyer request 1.2. The information given in buyer request 1.2 is used by Business 
Controller 2.0 to generate bargain price for the products meeting criteria as shown in box 
BF1.35. Criteria used in BF1.35 is searchable. Business Controller 2.0 searches product 
database 3.9 to get appropriate products for the buyer request 1.2 based on the criteria. The 
criteria in BF1.35 typically describes the required product, as well as the specific details of 
the product that the buyer wants to buy. The products typically include airline tickets, new 
and used cars, real estate, furniture, computer equipment, electronic equipment, tools, books, 
magazines, and the like. There may be a specific format for the criteria, requesting the buyer 
to use a given set words and symbols such as "model = 99", "No. Of seats ==5", "Mileage <= 
2000", "make = Cadillac" and the like for used cars, or it can be "capacity >= 8GB", 
"manufacturer = Seagate", "price <= 10000" and the like for a buyer interest in buying a new 
hard disk. The buyer can also designate response time, payment mode and type of service as 
criteria of buyer request 1.2. 
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Referring back to Figure BF1, the buyer then converts buyer request 1.2 into 
electronic format at step BF1.5 and is transmitted to Business Controller 2.0 at step BF1.6. 
This transfer occurs via electronic mail, the system also supports voice mail, facsimile or 
postal mail transmissions of buyer request 1.2. Buyer request can also be posted to bulletin 
boards or web pages operated by Business Controller 2.0. In a web-based embodiment, 
buyers may fill out an electronic form built into the web pages of Business Controller 2.0. 

It should be noted that the generation and transmission of buyer request 1 .2 does not 
require the use of proprietary software. Conventional electronic mail software such as 
Outlook Express, for example, is capable of providing editing tools for the creation of 
messages as well as the communication tools to route the message to the appropriate 
electronic mail address. As long as the message conforms to standards established by the 
Business Controller 2.0, an email program is capable of generating and transmitting buyer 
request. 

The standard would specify the message address, the information to be contained in 
the subject heading, and the processing order of the body of the message. The first line of 
the body of the electronic mail, for e.g. may contain the ID of the buyer. The second line is 
the product, third line the model and the fourth line the price buyer is willing to pay. 
Standard forms could also be electronically mailed to the buyer, allowing him to simply fill 
in the blanks and return buyer request 1.2 to Business Controller 2.0. Similar forms and 
standards could be applied to fax and postal mail transmission. 

Referring to Figure BF2, there is shown a flow chart for the case where the initial 
processing of buyer request 1.2 and first response generation by Business Controller 2.0 is 
intentional. Buyer request 1.2 is received, stored and processed by Business Controller 2.0 
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before generating a response. At step BF2.1, buyer request 1.2 is received from the buyer. 
Business Controller 2.0 supports all transmission methods allowing for a wide variety of 
formats of incoming buyer request. Some formats may be changed before further processing 
by Business Controller 2.0. Buyer request 1.2 transmitted by mail in paper form, for 
5 example, is scanned and digitized, using optional character recognition software to create 
digital text. Once buyer request 1.2 has been received, it is stored in request database 3.5 
where it is assigned a unique tracking number. 

After being stored at step BF2.1, buyer request may go through a series of processing 
steps. One step, if necessary, is language translation. There are two forms of language 
40 translation. With the first form, a standard language is created in which all buyer request 1.2 
must be written. Business Controller 2.0 extracts data from the buyer requests. The second 
~ : form requires translation to the language most appropriate for the buyers and sellers and 
Business Controller 2.0. This translation is provided by language experts associated with the 
system, or by automatic translation software such as Systran Professional, manufactured by 
15 "Systran" software. Twelve bi-directional language combinations are available, including 
English to/from French, Italian, German, Spanish, Portuguese and Japanese. 

Another processing step, if necessary, involves a check for spelling or typographical 
errors. Buyer request 1.2 is reviewed for clarity. Errors detected in Buyer request 1.2 are 
returned to the buyer for clarification and error removal. 

20 One processing step comprises a search for criteria. If no criteria have been 

included, the buyer request is returned to the buyer for resubmission. The buyer can 
alternatively provide criteria by selecting the buyer request product directly via online 
connection as described hereinafter in the Synchronous Bargaining embodiment. 
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If the buyer does not want to provide criteria, buyer request 1.2 may be classified by 
searching (i) the request for predetermined key words, or (ii) a list stored in product database 
3.9. Key words thereby developed are then used to generate criteria. Product database 3.9 
includes a list of keywords associated with the products. The presence of one or more of 
those key words in the request triggers a classification of the request as the appropriate 
product. 

One commercially available software package, which performs these types of 
searches, is Semantic Networks by Excalibur Technologies Corporation. The software 
provides the ability to retrieve approximations of search queries and has a natural tolerance 
for errors in both input data and query terms. Such software also provides a high level of 
confidence that searches will be successful regardless of errors in spelling of the data being 
searched. Excalibur' s baseline semantic network supports multi-layered dictionary, 
structures that enable integration of specialized reference works for legal, medical, finance, 
engineering and other fields. 

Excalibur Retrieval Ware enables developers to build information retrieval solutions 
for the full spectrum of digital information, including text, document images and multimedia 
data types. It allows for indexing and retrieval of digital images based on their objective 
context. These components enable pattern recognition based image retrieval applications that 
automatically recognize certain types of visual information and provide extensive image 
management capabilities. 

Before searching for the product meeting the criteria in product database 3.9, 
Business Controller 2.0 searches for previous requests from the buyer for the same product 
number at step BF2.2, so that unnecessary bargaining is not performed. At step BF2.3, if the 
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Business Controller 2.0 had accepted a buyer suggested bargain price earlier, but the buyer 
did not proceed to purchase the product at that time, and now wants to continue, there is 
generally no need to repeat the initial phase of the bargaining process. The buyer can, 
instead, be allowed to hold his bargain price for a limited time, or for an indefinite time, or 
5 until the product is purchased by another buyer. 

If there exists a system accepted, buyer requested bargain price for a product, and the 
buyer has not yet purchased the product, and has placed his bargain price on hold, then at 
step BF2.6, if buyer signals his intent to purchase the product, Business Controller 2.0 will 
present the buyer with higher bargain prices then extant, which have been offered by other 

10 buyers, to allow buyer to match or better the extant higher bargain prices. In the event there 
exist no higher bargain prices, Business Controller 2.0 will process the payment and ship the 
product to the buyer. In the event that the product has been purchased at a higher bargain 
price, Business Controller 2.0 creates a bargain price 1.2 at step BF2.4 provided the product 
is still available. If the product requested is no longer available, or buyer is not willing to 

15 match or better the higher bargain prices, then at step BF2.5, Business Controller 2.0 
generates from product database 3.9 a list of product closely meeting the criteria in buyer 
request but differing in certain respects, such as brand name, quality, color, features and the 
like. The list generated from product database 3.9 is then presented to the buyer for 
consideration, and the process is continued, as described herein, with buyer selecting a 

20 product from the list presented by Business Controller 2 .0 . 

After presenting the buyer with the higher bargain offers by other buyers, Business 
Controller 2.0 checks at step BF2.7 whether or not the buyer's bargain price revised in light 
of such higher bargain offers, is successful. If it is, then Business Controller 2.0 asks the 
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buyer to accept the bargain at step BF2.8. When the buyer accepts the offer at step BF2.9, 
Business Controller 2.0 finalizes the deal by billing the buyer and dispatching the product to 
the given address at step BF2.11. If buyer does not accept, then Business Controller 2.0 
continues with the bargain process at step BF2.10 until a successful bargain is arrived at. In 
5 the event that the buyer's revised bargain price is not successful, then Business Controller 
2.0 generates a new bargain price for the buyer and proceeds with the bargaining at step 
BF2.12 and BF2.13, and the process is continued as described herein. 

In Fig. BF3 there is illustrated another method of buyer request processing. Business 
Controller 2.0 assigns a tracking ID to each buyer request and, after receiving the request, 

- 1 0 stores it in request database 3 .3 at step BF3 . 1 . Upon receiving a buyer request, the Business 
Controller searches at step BF3.2, Business Controller 2.0 to determine whether there exists 
in request database 3.3 a similar request by the same buyer for the same product and whether 
the request was successful. In the event that a similar bargain request exists at step BF3.3, 

~ the buyer is notified about the bargain prices submitted by previous requests and whether 
15 such previous requests were successful at step BF3.6. If no similar requests exist at step 
BF3.3, then Business Controller 2.0 creates a bargain price in the form of a new bargain 
request using the criteria at step BF3.4. At step BF3.7, buyer has the option of either 
accepting the old bargain price or continue bargaining. If buyer chooses to accept the old 
bargain price, the Business Controller 2.0 checks at step BF3.8 to determine whether or not 
20 the product is available. If the product is available, buyer is notified about bargain request 
acceptance at step BF3.11, and billed at step BF3.12. If the product is not available, or a 
price has not been agreed upon, then Business Controller 2.0 generates a list of products 
closely meeting the criteria but differing therefrom in some minor respect, such as brand 
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name, quality, color, features and the like, by searching through the product database 3.9 at 
step BF3.5. Business Controller 2.0 so informs buyer at step BF3.9 and asks him to send 
another request at step BF3.10. 

In the event that the buyer refuses to accept the previous bargain price at step BF3.7 
5 and the product requested or a product closely meeting the criteria, as described above, is 
available, Business Controller 2.0 (i) offers to accept the previous bargain price, as applied 
to purchase of product having closely matched but slightly dissimilar attributes, such as 
different brand name, quality, color, features and the like, or (ii) generates a new bargain 
price for purchase of the same product and proceeds with the bargaining process at steps 
flO BF3.13 and BF3.14. 

Referring to Figure BF4 of the drawings, there is illustrated a process for offline 
bargaining in which Business Controller 2.0 bargains with more than one buyer. At step 
BF4.1, Business Controller 2.0 generates a bargain price for buyer request. This bargain 
price response is transmitted to the buyer at step BF4.2. If the buyer does not accept the 

1 5 bargain price at step BF4.3 then, at step BF4.4, Business Controller 2.0 is notified about the 
denial. Business Controller 2.0 asks buyer for another bargain price of his choice at step 
BF4.5. If the buyer accepts the bargain price at step BF4.3 then, at step BF4.6, acceptance is 
sent to Business Controller 2.0. At step BF4.7, Business Controller 2.0 checks the presence 
of more than one buyer bargaining for the same product. If only one buyer exists then he is 

20 informed about the request approval at step BF4.8 and then the buyer is billed at step BF4.9. 

If at step BF4.7 there is more than one buyer bargaining, then Business Controller 
2.0 checks for the availability of that product at step BF4.10. In the event that there is 
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available sufficient quantity of product requested, Business Controller 2.0 continues 
bargaining at step BF4.1 1 and, at step BF4. 12, bills the buyer. 

If the condition arises that only one piece of the requested product is available at step 
BF4.10, Business Controller 2.0 notifies the buyer offering the maximum bargain price that 
5 his bargain request has been approved at step BF4.13. Thereafter, at step BF4.14, Business 
Controller 2.0 notifies other buyers about the deal, stops running bargain process with them 
and, at step BF4.15, initiates the billing process for the successful buyer. 

In Figure BF5 there is illustrated the bargain price generation process by Business 
Controller 2.0 during bargain negotiations with buyer. After generating bargain price for the 

10 buyer at step BF5.1, Business Controller 2.0 attaches a product ID and stores it in response 
database 3.4 at step BF5.2, before sending this bargain price to the buyer at step BF5.3. If 
the buyer accepts the bargain price at step BF5.4, Business Controller 2.0 initiates the billing 
process at step BF5.6 and dispatches the product to the buyer at step BF5.7. Business 
Controller 2.0 initiates the payment process for the seller or vendor or manufacturer of the 

15 product at step BF5.8. In the event of buyer refusal at step BF5.4, Business Controller 2.0 
asks buyer for his next best bargain price at step BF5.5, and the process is continued, as 
described herein. 

Offline Communications with Seller 

Another feature of the Internet Bargaining System is the ability to provide for offline 
20 bargaining and communications between the seller and Business Controller 2.0. In Figure 
SF1 there is shown a method wherein the seller registers himself with the Business 
Controller 2.0. At step SF1.1 seller creates his profile, and at step SF1.2, specifies his name, 



29 

address, phone number and the like. Seller converts his profile and, preferably, details about 
mode of payment into electronic format at step SF1.3. This data is then transmitted to 
Business Controller 2.0 at step SF1.4. As described earlier, this transfer occurs via 
electronic mail, voice mail, facsimile or postal mail transmissions. 

5 Generation and transmission of seller profile data does not require proprietary 

software. Conventional e-mail software such as "Outlook Express", for example, provides 
editing tools for creation of messages, and communications tool to route these messages to 
the appropriate e-mail address. As long as a message conforms to the standards established 
by Business Controller 2.0, any e-mail program can perform the required function. The 

10 standard specifies the address to send messages to, as well as the format of information 
contained in the subject and the body of the message. Standard forms can be electronically 
mailed to the seller, allowing the seller to complete the forms by filling in the blanks and 
returning the forms to Business Controller 2.0. Business Controller 2.0 updates seller 
database at step SF1.5 and generates a unique ID at step SF1.6 for seller authentication in 

15 future. This ID number can contain a login name and password. The generated ID is then 
transmitted back to seller at Step SF1.7. Seller can use the ID number (i) to get authorization 
from the system for sale of the product (or to sell another product at some other time), or (ii) 
for present or future correspondence. 

Figure SF2 illustrates an embodiment in which the seller submits product details. At 
20 step SF2.1 the seller creates a product profile giving specific details about his product, for 
example, category, type, make, model, color, type and the like, as shown in SF2.2. The 
seller attaches his ID number with the product profile for authorization at step SF2.3. 
Thereafter, at step SF2.4, the seller converts the product profile into electronic format and 
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transmits his request to Business Controller 2.0, at step SF2.5. Transmission of the request 
at step SF2.5 can, alternatively, be accomplished by facsimile or regular mail. As used 
herein, the term "regular mail" includes first class, or faster, mail delivery, such as express 
mail, federal express, courier, messenger and the like. Business Controller 2.0 updates 
5 product database, at step SF2.6, and at step SF2.7 Business Controller 2.0 transmits a 
response containing the seller request and conditions of sale. 

Reference is now made to Figure SF3, in which Business Controller 2.0 performs the 
creation and initial processing of the seller request 1.4. Seller creates seller request 1.4 at 
step SF3.1, converts it into electronic format, facsimile or regular mail at step SF3.2 and at 

10 step SF3.3 transmits it to Business Controller 2.0. At step SF3.4 Business Controller 2.0 
checks if the request is acceptable or not. If the request is not accepted then, at step SF3.5, 
Business Controller 2.0 asks the seller to send the request again or create a new request. At 
step SF3.4, if Business Controller 2.0 accepts the request then product database 3.9 is 
updated at step SF3.6. Then Business Controller 2.0 starts the process of evaluation of the 

15 product at step SF3.7, and at step SF3.8 Business Controller 2.0 generates a response 
according to the mode of sale specified in the request by the seller. 

In Figure SF4 there is illustrated the related processes occurring when the seller 
wants to sell his product to Business Controller 2.0, or the seller wants Business Controller 
2.0 to put his product on sale. At step SF4.1, Business Controller 2.0 evaluates seller 
20 request and checks whether this is an acceptable request at step SF4.2. If the request is not 
acceptable, then Business Controller 2.0 sends a rejection notification to seller at step SF4.3 
and asks seller to create a new request at step SF4.4. If, at step SF4.2, the request is 
accepted then Business Controller 2.0 checks the mode of sale at step SF4.5. In the event 
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that the mode of sale in the request is to put the product on open sale, then Business 
Controller 2.0 puts the product on the selling list, adds a predetermined percentage typically 
at least about .001%, preferably about .05% to 1000%, and more preferably about .10 to 
20% based on the offering sale price of the product or service, and updates respective 
5 database at step SF4.6. As used herein, the term "open sale" means sale of the product, by 
auction, bargaining, or retail or wholesale listing thereof, without active participation by the 
Business Controller 2.0. At step SF4.7 Business Controller 2.0 checks whether the product 
is sold or not. If the product is sold then Business Controller 2.0 sends notification to the 
? seller about the deal at step SF4.8 and, at step SF4.10, initiates the payment process for the 
:i0 seller in accordance with the conditions of sale. If the product is not sold, then at step SF4.9, 
the Business Control 2.0 continues to sell the product until (a) the product is sold, (b) the 
product is withdrawn by the seller, or (c) the time limit for listing the product has expired. 
Referring again to step SF4.5, if the mode of sale is bargaining i.e. the seller wants to sell the 
product to the Bargaining System or to a buyer with active participation by the Business 
15 Controller 2.0 at a bargained for price, then Business Controller 2.0 generates a bargain 
price for the seller, adds a predetermined percentage typically at least about .001%, 
preferably about .005% to 1000%, and more preferably about .10 to 20% based on the final 
sale price of the product or service, and updates response database 3.4 and step SF4.1 1. In 
the event that the seller accepts the bargain price at step SF4.12, then at step SF4.13 
20 Business Controller 2.0 either initiates the payment process to seller in accordance with the 
conditions of sale, or actively bargains with prospective buyers to arrive at a mutually agreed 
upon bargain price for sale of the product and initiates payment to seller as per the 
conditions of sale. If the seller does not accept the bargain price, then Business Controller 
2.0 continues with the bargaining process at step SF4.14. 
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Referring to Figure SF5 there is illustrated the inquiry process used by the seller to 
inquire about the sale of his product. At step SF5.1, seller creates inquiry request, attaches 
his ID number for authorization and transmits the request to Business Controller 2.0 along 
with product ID at step SF5.2. Thereafter, at step SF5.3, Business Controller 2.0 checks the 
sale status of the product ID specified in the inquiry request. If the product has been sold, 
the Business Controller 2.0 provides details of the sale and the agreed upon terms and 
conditions of sale. If the product is still listed for sale, then at step SF5.4, Business 
Controller 2.0 provides information about current and previous bargain offers. Business 
Controller 2.0 then asks the seller to transmit his comment about the sale status at step SF5.5 
which comment may include a revised request to list the product with certain purchase 
incentives, or at a revised purchase price. 

Synchronous Bargaining Embodiment 

In one embodiment of the present invention, buyers and sellers requiring continuous 
interaction with the system establish a synchronous communication channel with the system. 
Inasmuch as the present invention is based on a bargaining system, real-time system 
communication is preferred instead of the asynchronous communication protocol. There are 
various methods that buyers and sellers can use to communicate with the system. Protocols 
for communications between one buyer and the system and between one seller and the 
system are described hereinafter in further detail. In the embodiment describing buyer- 
system communications, the buyer and system exchange a series of buyer requests and 
bargain responses using a one-to-one synchronous communications channel such as 
telephone, real-time text messaging, voice recognition and response systems, dynamic web 
pages, chat rooms on the Internet, wireless communication such as cell phones or Palm 



Pilots, and the like, or video conferencing. The same mechanism exists for the case of 
seller-system communications, in which the seller and system exchange seller requests and 
bargain responses. Buyer can request a synchronous communication channel when making 
an initial buyer request 1.2, using any of the embodiments of the present invention. If 
5 buyer's criteria includes a request for voice communications, Business Controller 2.0 
provides software enabling voice actuated computer communication, or assigns an expert to 
construct a synchronous voice or text-based synchronous communication channel. This 
mechanism is oftentimes employed for special cases; since Business Controller 2.0 is 
generally able to process the request and all steps of the bargaining process. 

10 Many synchronous communications channels may be used. For illustrative purposes 

an online messaging system is described which uses a standard online service to provide a 
real-time, text-based or voice-based communications link between the buyer and seller, as 
well as between the buyer or seller and Business Controller 2.0. 

Online Bargaining with Buyer 

15 In Figure BN1, there is illustrated a method by which buyer creates a profile and 

registers with the system online. Buyer connects to an online service at step BN1.1. This 
online service could be from any Internet service provider (ISP), such as AOL, CompuServe, 
Prodigy, IBM, and the like. It will be understood by those skilled in the art that the 
connection can be a line connection such as a telephone line or cable connection, or a 

20 wireless connection, such as that made using a cell phone, Palm Pilot or the like. At step 
BN1.2 buyer connects to Business Controller 2.0 and submits the profile at step BN1.3. 
Here buyer provides buyer's name, address, phone number, e-mail address, city, state, 
country, preferred language and the like, as shown in box BN1.4. Business Controller 2.0 
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can require the buyer to provide this information in a predefined format. Alternatively, buyer 
may be required to fill out an online form for this purpose. Business Controller 2.0 updates 
buyer database 3.5 at step BN1.5 and the buyer becomes registered with the system. At step 
BN1.6, Business Controller 2.0 generates a unique ID number for the buyer. This ID 
5 number can contain a login name and password. This ID number is used by the buyer to get 
authorization for purchase of products from the system. It also permits buyer to purchase 
wild card discounts and bonus chances. The system may also award wildcard discounts, or 
special promotions on specific bargain deals, and/or award such wild card discounts and 
special promotions randomly or to privileged customers. Buyers are notified of such wild 

10 card discount awards by surprise pop-up messages, or by instant messaging, or by means of 
a "Bargain Guru". In addition, the system is further configured to award purchase incentives 
selected from the group consisting of: (a) bonus chances made available upon the purchase 
of products and/or services, or in response to buyer request for free bonus chances, or to 
encourage timely payment by regular customers and (b) purchase points provided upon 

15 purchase of products and services. The basis for providing purchase points will vary, 
depending on the price and quantity of product purchased, the referral of new purchasers 
and other product and service drivers, as may be referenced in the membership agreement. 

Buyer connects to Business Controller 2.0 to get information about new and future 
products. In addition, buyer can view the prices offered by the system. Buyer can make 
20 queries about the quality and state of products that are of interest for bargaining. At step 
BN1.7 Business Controller 2.0 notifies buyer about the completion of the registration 
process. In another embodiment of the invention, either buyer or seller can surf the Internet 
bargaining site for a predetermine period of time, preferably ranging from at least about 30 
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seconds, more preferably from about 1 minute to 10 hours, and still more preferably from 2 
to 7 hours, to determine product and service offerings. 

In Figure BN2 there is described an embodiment of this invention wherein the buyer 
selects a product and creates a buyer request. The system allows the buyer at step BN2.1 to 
5 establish an online connection to Business Controller 2.0 via the Internet, using an ISP such 
as AOL, CompuServe, Prodigy and the like or other conventional online system. Online 
services act merely as a convenient way for synchronous communications given their 
capacity to process tens of thousands of simultaneous connections. In another embodiment 
Business Controller 2.0 process all synchronous communications directly, eliminating the 

10 need for online networks. Buyer interface 5.0 displays a screen on video monitor 5.10 that 
offers a selection of predetermined product areas at step BN2.2, such as Airline Tickets, 
Real Estate, Cars, Sports Goods, and Antiques and the like, as described in box BN2.3. 
These product areas are stored in product database 3.9. Buyer selects a category and is 
presented with a list of products present in that category. Thereafter, buyer is prompted to 

1 5 select one of them at step BN2.4. 

Step BN2.4 can consist of several steps that may include further selection of sub- 
categories related to the product. These categories help the buyer to further refine the 
criteria of his request. At step BN2.6 buyer finalizes the choice of product. At step BN2.7 
Business Controller 2.0 generates a product ID against the criteria submitted by the buyer. 
20 Bargain request 1.2 is created at step BN2.8, which includes the buyer's bargain price and, 
optionally, the payment preference suggested by the buyer such as credit card, EFT, or 
digital cash as shown at step BN2.9. 
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In Figure BN3 there is shown (i) the process used by buyer to make his request to 
Business Controller 2.0 after selecting the product online; and (ii) how the Business 
Controller 2.0 initiates the bargain process. At step BN3.1, buyer's request, buyer ID and 
product ID are combined to buyer request 1.2. This buyer request 1.2 is then transmitted to 

5 Business Controller 2.0 at step BN3.2, and at step BN3.3 Business Controller 2.0 stores 
buyer request 1.2 in bargain request database 3.3. At step BN3.4 Business Controller 2.0 
decides whether or not the request can be accepted. If Business Controller 2.0 does not 
accept the request, then at step BN3.5, Business Controller 2.0 checks the product database 
for alternative products. If no alternative product is found, then at step BN3.6, Business 

10 Controller notifies the buyer about the rejection of the request and stops bargaining. The 
appropriate reason of rejection is shown to the buyer through buyer interface 5.0 at step 
BN3.6. The basis for rejection could be (i) that the product may not be available at that time; 
or (ii) that the product has already been sold; or (iii) that the service is not selling products in 
that category; or (iv) that the price is below the final bargain price, or (v) that the bargaining 

15 chances have been exhausted, or (vi) the time allotted for bargaining has expired. At step 
BN3.1 1 Business Controller 2.0 updates its database and stops all transactions related to this 
process. For cases in which the product is unavailable or has already been sold, or for which 
the buyer request price is too low, at step BN3.5, Business Controller 2.0 generates a list of 
products closely meeting the criteria (ie. price, product description and conditions of sale) 

20 set forth in buyer's request, but differing therefrom in some minor respect, such as brand 
name, quality, color, features and the like. Business Controller 2.0 generates this list of 
products by searching through the product database 3.9. The Business Controller 2.0 so 
informs buyer at step BF3.12 and at step BN 3.13 asks the buyer to accept the alternative 
product. If buyer does not accept the alternative product, then at step BN3.14 buyer may 
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nevertheless submit a modified request, and at step BN3.15 the bargaining process is 
continued until a bargain price is mutually arrived at, the alternative product becomes 
unavailable or one of the parties discontinues the process. If Business Controller 2.0 accepts 
buyer request 1.2 at step BN3.4 then Business Controller 2.0 generates a response for the 
5 buyer in the form of a bargain price acceptance at step BN3.7. This response is transmitted 
to the buyer at step BN3.8 and Business Controller 2.0 bills the buyer at step BN3.9. 

Referring to Figure BN4, the initial processing of buyer request 1.2 and first 
response generation by Business Controller 2.0 is illustrated. Buyer request 1.2 is received, 
stored and processed by Business Controller 2.0 before generating a response. At step 
10 BN4.1, buyer request 1.2 is received from the buyer. Once buyer request 1.2 has been 
received, it is stored in request database 3.5 where it is assigned a unique tracking number. 

After being stored at step BN4.1, buyer request may go through a series of 
processing steps. One step, if necessary, is language translation. There are typically two 
forms of language translation. In the first translation form a standard language is created in 

15 which all buyer request 1.2 must be written. Business Controller 2.0 extracts data from the 
buyer requests. The second translation form comprises translating to the language most 
appropriate for the buyers and sellers, and Business Controller 2.0, as described in earlier 
embodiments. Buyer request 1.2 containing errors will be returned to the buyer for 
clarification and error removal. In a further processing step, the request is searched for 

20 criteria, and if no criteria have been included, buyer request is sent back to the buyer for 
resubmission. Language translation is not required if the language used meets the preferred 
language criteria defined by the registration profile of both seller and buyer. The Internet 
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Bargaining System is equipped with language translation software that enables it to 
communicate with both buyer and seller in a multilingual environment. 

Before searching for the product meeting the criteria in product database 3.9, 
Business Controller 2.0 searches at step BN4.2 for previous requests from the buyer for the 
5 same product number that was accepted by the Business Controller 2.0, so that unnecessary 
bargaining is not performed. If the buyer had already suggested his bargain price earlier but 
did not proceed at that time, and now wishes to continue, then there is no need to start all 
over. In this instance, the buyer can be allowed to hold his bargain price for: (i) a limited 
time, or (ii) an indefinite time, or (iii) until the product is bought by another buyer. 
10 Alternatively, the buyer can input the transaction tracking number to retrieve the bargain 
price previously accepted by the system and kept on hold by buyer. 

In the event that the buyer has previously requested a bargain price for that product at 
step BN4.3, then Business Controller 2.0 will present the buyer with higher bargain prices 
offered by other buyers at step BN4.5, or provide to buyer additional purchase options, such 

15 as (i) average price paid by other buyers, or (ii) the selling price of the product on other web 
sites (i.e. comparative price quotes). If the product is not available, or a price has not been 
agreed upon, then Business Controller 2.0 generates a list of products closely meeting the 
criteria but differing therefrom in some minor respect, such as brand name, quality, color, 
features and the like, by searching through the product database 3.9 at step BN4.4. The 

20 process is thereafter continued in the manner described hereinabove in connection with the 
portion of the specification involving offline communication with the buyer. 

After presenting the buyer with the higher bargain offers by other buyers, Business 
Controller 2.0 checks at step BN4.6 whether or not the buyer's bargain price revised in light 
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of such higher bargain offers, is valid. If it is, then Business Controller 2.0 asks the buyer to 
accept the bargain at step BN4.9. When the buyer accepts the offer at step BN4.10, Business 
Controller 2.0 finalizes the deal by billing the buyer and dispatching the product to the given 
address at step BN4.12, and sends invoice and shipping details either through an electronic 
email system or through regular mail. If buyer does not accept, then Business Controller 2.0 
continues with the bargain process at step BN4.1 1 until a successful bargain is arrived at. In 
the event that the buyer's revised bargain price is not valid, then Business Controller 2.0 
generates a new bargain price for the buyer and proceeds with the bargaining at step BN4.7 
and BN4.8, and the process is continued as described herein until a bargain price is mutually 
reached, the product becomes unavailable, or one of the parties discontinues the bargaining 
process . 

In Figure BN5 there is show the process of online bargaining between buyer and 
Business Controller 2.0. At step BN5.1 buyer connects to an online service as shown in box 
BN5.2. A communications channel is opened at step BN5.3 between Business Controller 2.0 
and the online service. The communications channel is a direct link such as a circuit 
switched or packet switched network connection, or it can also be an Internet connection or 
a wireless connection as described previously. Once this connection has been made, the 
buyer provides his ID number at step BN5.4 and payment information at step BN5.5. 
Alternatively, provision of the buyer's ID number and payment information may be deferred 
until such time as purchase of a product or service is imminent. Payment information can 
include a credit card account number, bank account number or other payment method as 
shown in box BN5.6. After the buyer has been authorized to enter the system, he either 
selects a product from the list of products or he can select by searching through product 
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database 3.9 as described earlier at step BN5.7. Once a product has been selected, Business 
Controller 2.0 generates bargain responses against the subsequent bargain requests that 
include bargain price offers at step BN5.8. At step BN5.9 Business Controller 2.0 
determines whether the final bargain price is decided or if the buyer wants to exit. If buyer 
does not accept, then Business Controller 2.0 at step BN5.11 continues with the bargain 
process until a successful bargain is arrived at. In the event that the buyer's revised bargain 
price is not successful, then Business Controller 2.0 generates a new bargain price at step 5.8 
for the buyer and proceeds with the bargaining process, and the process is continued as 
described herein until (i) a bargain price is mutually reached, (ii) the buyer exhausts all 
bargaining time allocated for the product, (iii) buyer exhausts all free chances available at 
buyer registration or issued thereafter pursuant to the registration agreement, (iv) the buyer is 
unwilling to request or purchase additional bargaining time or bargain chances, (v) the 
product becomes unavailable, or (vi) one of the parties discontinues the bargaining process . 

If the buyer does not agree on a final bargain price for that product at step BN5.9, 
then Business Controller 2.0 continues the bargaining process at step 5.10 as previously 
provided or exits. On the other hand, if a final bargain price is agreed upon, the Business 
Controller 2.0 starts the billing process at step BN5.1 1 and the product is dispatched to the 
buyer and invoice and shipping details are sent to the buyer electronically or through regular 
mail. This process also initiates the payment process to the seller of that product. 

Referring to Figure BN6 there is described a process of online bargaining in which 
Business Controller 2.0 bargains with more than one buyer. At step BN6.1, Business 
Controller 2.0 generates a bargain price for buyer request. If the buyer does not accept the 
bargain price at step BN6.2, then Business Controller 2.0 asks buyer for another bargain 
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price of Ms choice at step BN6.3. If the buyer accepts the bargain price at step BN6.2, then 
at step BN6.4, Business Controller 2.0 checks the presence of more than one buyer 
bargaining for the same product. If only one buyer exists then that buyer is informed about 
the request approval at step BN6.5 and then the buyer is billed at step BN6.6. If at step 
BN6.4, there is more than one buyer bargaining, then Business Controller 2.0 checks for the 
availability of that product at step BN6.7. In the event that the quantity of product desired is 
sufficient, then at step BN6.10 Business Controller 2.0 bargains individually with each buyer 
for sale of the product, as described herein. In the event that the quantity of product desired 
is limited, then at step BN6.8, Business Controller 2.0 informs the buyers concerning the 
limited product availability and at step BN6.9 sends a message to all buyers ask them 
whether they wish (i) to meet or beat the highest price then offered for the product or (ii) to 
submit a final bargain price for the product. Thereafter, Business Controller 2.0 initiates the 
billing process for the successful buyer at step BN6.1 1 . 

Figure BN7 describes an embodiment in which a continuous communications 
channel is established between the buyer and Business Controller 2.0 using a message 
window. This message window can be a text-based computer "window" displayed on video 
monitor 5.10 of buyer interface 5.0. The buyer types buyer requests 1.2 directly to message 
window in a format specified by Business Controller 2.0 that appears on video monitor 5.10. 
Simultaneously Business Controller 2.0 processes these messages and generates responses 
for the buyers, which are then displayed on buyer's video monitor 5.10. 

At step BN7.1 buyer selects product by entering a message in a message window and 
inputs buyer request 1.2 through buyer interface 5.0, the buyer and Business Controller 2.0 
exchange a plurality of bargain requests and bargain responses at step BN7.2. These requests 
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and responses contain the suitable bargain prices for both of them. If a bargain price has not 
been agreed at step BN7.3, and buyer has chosen not to pursue the system provided 
bargaining options defined herein, then buyer exits message window at step BN7.4 without 
buying the product. If the buyer and Business Controller 2.0 come to agreement on a bargain 
price, then the buyer leaves the message window at step BN7.5 using a log off procedure 
where he signals that a successful session has ended. At step BN7.6 all the relevant 
databases are updated to depict a successful transaction. The buyer account is billed using 
the various billing methodologies described in the billing embodiment at step BN7.7, and at 
BN7.8 the product is dispatched to the buyer. 

Online Bargaining with Seller 

Figure SN1 describes the method by which the seller registers himself with Business 
Controller 2.0. At step SN1.1 seller connects to the online service. This online service could 
be AOL, CompuServe, Prodigy or other conventional online service providers. At step 
SN1.2 seller connects to Business Controller 2.0 and submits seller's personal profile at step 
SN1.3. Here seller may be asked to submit such items as name, address, phone number email 
address, city, state, country and the like, as shown in box SN1.4. This profile could be in a 
predefined format or seller may be asked to file an online form for this purpose. At step 
SN1.5 Business Controller 2.0 updates seller database and registers seller. Business 
Controller 2.0 generates a unique ID for the seller at step SN1.6. This ID number is used to 
get authorization from the system if the seller wants to communicate or sell another item at 
some other time. Seller can connect to Business Controller 2.0 using this ID to get 
information about the status of seller's product sale or any other queries. At step SN1.7 
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Business Controller 2.0 asks the seller to provide characteristics of the product to be put on 
sale. 

Figure SN2 illustrates the process by which the seller connects to Business 
Controller 2.0 and submits product characteristics to be put on sale. At step SN2.1 seller 
connects to online service, as described earlier. Thereafter seller connects to Business 
Controller 2.0 at step SN2.2. Here the seller provides his ID number along with the 
password for authorization at step SN2.3. At step SN2.4 the seller submits the characteristics 
of seller's product. These characteristics may be submitted using a predefined format 
specified by the Business Controller 2.0, or he may be asked to fill an online form for this 
purpose. This form may contain all the necessary details about the product that may be 
necessary to assess the value of that item by the Business Controller 2.0. The seller can also 
provide a photograph of the object in electronic format, if required. Product characteristics 
may contain information about the product, including category, make, model, year, type and 
the like, as described in box SN2.5. At step SN2.6, the seller specifies the mode of sale that 
is preferred for seller's product, for example, bargaining or open sale, as specified in box 
SN2.7. 

Seller can specify that the product is to be sold in a limited period of time. This way 
Business Controller 2.0 can bargain with the interested buyer to come up with an optimum 
price for the product. One method includes placing the product on auction for purchase by a 
buyer that submits the highest bid. Another method can include selling the product to 
Business Controller 2.0 which, in turn, bargains with the seller to give seller his best bargain 
price range, after adding sales commission, license royalty, or other such transactional fee, 
and then later sells the product to the buyers. Yet another method can include listing the 
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product through the Business Controller 2.0 and paying a sale commission based on minimal 
participation by Business Controller 2.0, bargaining directly with a prospective buyer for 
sale of the product. Still another method can include listing the product through the 
Business Controller 2.0 which, in turn, bargains with the seller to arrive at a price range for 
5 the product and, after adding sales commission, license royalty, or other such transactional 
fee, bargains directly with the seller to arrive at a final sales price for the product. These 
represent some of the methods that can be used, but it will be appreciated by those skilled in 
the art that many different methods or combinations of methods could be used, as well. 

At step SN2.8 Business Controller 2.0 updates seller database and product database 
10 and generates a response at step SN2.9 according to the mode of sale preferred. 

Referring to Fig. SN3, there is described the manner in which Business Controller 
2.0 does the initial processing of the seller request 1.4. After the seller submits his request to 
Business Controller 2.0 at step SN3.1, Business Controller 2.0 determines at step SN3.2 
whether the request is acceptable. The request should be in a format specified by Business 

15 Controller 2.0. Business Controller 2.0 can specify this format in an electronic form posted 
on its web page. The seller fills the form and submits it to Business Controller 2.0. Business 
Controller 2.0 then extracts all the required data and stores it in request database 3.3. In 
addition, Business Controller 2.0 determines whether the product appointed for sale can in 
fact be sold through Business Controller 2.0. This determination is made by processing 

20 through the Business rules component 2.8 of the Business Controller 2.0. If the request is 
not acceptable, then at step SN3.3 Business Controller 2.0 asks seller to send another request 
or modify the previous one. At step SN3.2, if the request is accepted then at step SN3.4 
Business Controller 2.0 updates the request database and product database 3.9. Business 
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Controller 2.0 starts the evaluation of the product at step SN3.5. Mode of sale for the request 
is checked at step SN3.6 and if it is to be put on sale then Business Controller 2.0 puts the 
product on sale at step SN3.7. If the seller wants to sell the product to the Business 
Controller 2.0, or sell or list the product through the Business Controller, as described 
5 herein, then Business Controller 2.0 generates a response for the seller request at step SN3.8. 
If the seller accepts the bargain price offered by Business Controller 2.0 at step SN3.9, then 
at step SN3.10 the product is listed for sale by bargaining. If the seller bargain price offered 
is not accepted then the seller at step SN3.11 continues the bargaining process until an 
agreement is reached or the seller decides to exit the system. 

10 In Figure SN4 there is illustrated the transactions involved when the seller wishes his 

product to be on open sale. The sale of seller's product may be accomplished by auction, 
bargaining or at fixed price. The system can be configured to place items on auction or to 
sell items procured using a procedure involving bids taken from a plurality of buyers, 
wherein the product is sold to the buyer with the highest bid. At step SN4.1 seller submits 

15 his product to be sold through Business Controller 2.0. Business Controller 2.0 updates the 
product database at step SN4.2 and puts the product on its selling list at step SN4.3. This 
process can involve the generation of web pages wherein the product is advertised. The web 
pages are included in the buyer-searchable database so that buyers can access them. At step 
SN4.4 Business Controller 2.0 determines whether the product is sold. If the product has not 

20 been sold then a determination is made at step SN4.5 whether the time limit for selling the 
product has expired. If the limit expires then at step SN4.7 Business Controller 2.0 notifies 
the seller that the product was not sold during the preselected time period. At this time the 
seller and, or Business Controller 2.0 has the option of (i) extending the time limit, or (ii) 
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checking the unaccepted bargain offers related to the product and choosing whether to 
accept any one of those bargain offers, or (iii) re-listing the product at a lower price, or (iv) 
offering additional incentives to the buyer. If the seller elects to proceed on the basis of one 
of the preceding options, then Business Controller 2.0 proceeds in accordance with the 
5 selected option. One of these options would include contacting the buyer that presented the 
bargain offer which seller has elected to determine whether the buyer is still interested in 
proceeding. If the buyer is interested, then a bargain price is arrived at; but if the buyer is no 
longer interested, then the seller is notified and the product is re-listed by Business 
Controller 2.0 in accordance with the revised request. At step SN4.5 if the time limit is not 
-10 over then Business Controller 2.0 continues accepting bargain offers from the buyers at step 
SN4.6. If the product is sold at step SN4.4, then Business Controller 2.0 notifies seller about 
the deal and the price at which the product has been sold at step SN4.8. At the end of these 
processes, Business Controller 2.0 initiates the payment process at step SN4.9 in accordance 
with the agreed upon price and conditions of sale. 

15 Figure SN5 illustrates the process by which the seller bargains with Business 

Controller 2.0 to get the best bargain price for the product, sells it to Business Controller 2.0 
or sells or lists the product through the Business Controller 2.0 with minimal participation 
thereby. Therefore, at step SN5.1, the seller connects to Business Controller 2.0. Seller 
provides an ID number for authorization at step SN5.2. The seller requests Business 

20 Controller 2.0 to start bargaining by sending a bargain request to Business Controller 2.0 at 
step SN5.3 attaching a bargain price range. At step SN5.4 Business Controller 2.0 generates 
a bargain response for the seller, specifying a more suitable price for the product. At step 
SN5.5, Business Controller 2.0 determines whether or not the seller accepts that bargain 
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price range. If the seller accepts the price range then at step SN5.7 Business Controller 2.0 
either acquires the product from seller and initiates the payment process or lists the product 
through Business Controller 2.0 and initiates the payment process upon sale of the product. 
If the seller does not accept the bargain price range at step SN5.5, Business Controller 2.0 
5 asks seller to send another more suitable price range at step SN5.6. This process can 
continue until (i) the seller's best bargain price range is achieved, or (ii) Business Controller 
2.0 stops bargaining after generating a limited number of bargain prices, or (iii) the 
expiration of time or exhaustion of chances allotted for bargaining with the seller, or (iv) 
seller elects to list the product on open sale. The best bargain price range will include the 
10 final bargain price that Business Controller 2.0 can offer for the product. Business 
Controller 2.0 can hold that price for a preselected period of time, upon request, if the seller 
is undecided about the acceptance of the offer. This procedure permits seller to accept the 
final bargain price at a more convenient time. Seller can also reject the final bargain price of 
the Business Controller 2.0 if it is not satisfactory . 

15 Referring now to Fig. SN6, there is shown an embodiment in which the seller can 

inquire about the sale status of the product. At step SN6.1 seller connects to Business 
Controller 2.0 and provides seller's ID number for authorization at step SN6.2. At this point 
seller also provides the product ID and requests Business Controller 2.0 to provide seller 
with the status of sale of the product at step SN6.3. Business Controller 2.0 searches through 

20 the database and generates a report specifying the current and previous bargain offers at step 
SN6.4. At step SN6.5, this report is presented to seller and at step SN6.6 Business Controller 
2.0 asks the seller if seller is willing to accept any one of the offers yet made, or reduce the 
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price of the product, or offer additional incentives for sale of the product, or list the product 
on open sale. 

Buyer Bidding Process 

In one embodiment of the present invention, a procedure is described in which the 
buyer selects the products. Additionally, bidding and bargain negotiating procedures are 
described which allow the buyers to select the most appropriate product of their choice and 
get the best bargain. 

After Business Controller 2.0 has generated the list of related products, the buyer 
may directly choose one or more products. The buyer might connect to the web page of 
Business Controller 2.0 to select from the given list of products. Now when the selection of 
products has been made, the buyer can start bargaining on the total price of the selected 
products. This way the buyer does not require bargaining on each and every product. The 
Business Controller 2.0 is responsible for bargaining on the total price of the products. It 
keeps track of each item's price and processes each item's bargain price individually. This 
way the buyer is not concerned with the individual price of each product, instead he bargains 
for a package deal that is more suitable, convenient and cost effective. 

In another embodiment, if the seller wants to sell a number of products or a package 
containing several items, the Business Controller 2.0 then processes each item separately. 
The bargain price for each item is generated and summed to come up with a bargain price of 
the whole package. The system is capable of handling an unlimited number of buyers and 
sellers at the same time depending on the processing power of available hardware. 
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Fig BB1 shows a bidding embodiment where the buyer bids for a product. If the bid 
is greater than the final bargain price then system accepts the bid otherwise rejects the bid 
request and keeps the product open for bidding. Buyer creates a bid request at step BB1.1 
and transmits the request to Business Controller 2.0 at step BB1.2. At step BB1.3 Business 
Controller 2.0 checks in the bargain database whether the current bid meets the seller or 
system criteria. If the bid does not meet the seller or system criteria, then Business Controller 
2.0 updates the bargain database at step BB1.4 and continues to request a new bargain price 
until the time allocated for bidding has expired, or buyer's chances are exhausted and buyer 
is unwilling to purchase additional chances, or the product has been sold or is no longer 
available for sale, or alternative similar products have not been offered for purchase, as 
provided herein. In these circumstances, the Business Controller 2.0 notifies the buyer about 
the previous bids including the highest bid and asks the buyer to bid again at step BB1.5. 

In the alternative case, Business Controller 2.0 determines at BB1.3 whether a bid 
request meets the seller or system criteria. In these circumstances, the Business Controller 
2.0 then determines from the bargain database whether this current bid is greater than the 
final bargain price at step BB1.6. If it is not, then the database is updated at step BB1.7 and 
Business Controller 2.0 notifies buyer that this bid cannot be accepted and asks the buyer to 
bid again at step BB1.8. Now if this bid is greater than the final bargain price then Business 
Controller 2.0 updates the databases at step BB1.9 and the user is notified about the 
acceptance at step BB1.10. 

Referring to Fig. BB2, at step BB2.1 buyer creates buyer request. This request is then 
sent to Business Controller 2.0 at step BB2.2. At step BB2.3, the Business Controller 2.0 
analyzes the buyer request. This analysis can contain procedures to compare the requested 
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bid with the ones previously stored in the database or with the bids made by the same buyer, 
or provide assistance to the buyer. These procedures can also check whether the current bid 
is greater than the lowest or final bargain price. It is also possible to determine whether the 
product requested for is available for selling or not. At step BB2.4 the buyer is informed 
5 about the analysis of buyer request. The position of the current bid against comparative 
quotes is presented to the buyer. At step BB2.5 the Business Controller 2.0 continues the 
bidding process until the time period or chances allotted for bidding time are over, or the 
product is sold to one of the bidders, or the product is no longer available. At step BB2.6, 
Business Controller 2.0 notifies the successful buyer about the bid acceptance at the end of 
=10 the bidding process. 

Another form of bidding procedure is shown in Fig. BB3. At step BB3.1 buyer 
submits buyer request to Business Controller 2.0. Business Controller 2.0 processes request 
and updates relevant databases at step BB3 .2. At this point, after processing the request, 
Business Controller 2.0 checks its databases to determine whether the bid request can be 

1 5 accepted or whether it should ask the buyer for a higher bargain price at step BB3 .3 . If the 
bid is acceptable then Business Controller 2.0 notifies buyer about the bid acceptance and 
initiates the billing process at step BB3.4. If the bid is not accepted at step BB3.3 then 
Business Controller 2.0 at step BB3.5 informs buyer that buyer's bid is either lower than 
final bargain price or lower than the highest bid yet made, or suggests alternative products 

20 having similar features, or offers additional bidding assistance, as provided herein. At step 
BB3.6, Business Controller 2.0 presents the buyer with additional bidding incentives, such 
as bidding discounts (e.g. buy now, pay later or by one, get one free, bonus airline miles, free 
gifts, free shipment of product, product personalization by monograms or initials, and the 
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like), or provides bidding information, including (i) a list of current bids, or (ii) average bids 
submitted, or (iii) comparative quotes submitted, and (iv) the minimum bargain price, or (v) 
suggested modification of the bidding price, and asks the user to bid again. At step BB3.7 
buyer decides to change his request or increase his bid in order to be successful, thus 
5 continuing with the bidding process. 

The bidding processes described here can be used with any of the given 
embodiments. It can use either an asynchronous or synchronous communications 
embodiment. When the bidding period terminates or the number of permissible bids is 
exhausted, the process of billing is started and the successful bidder is billed. The payment 
~1 0 process follows the billing process where Business Controller 2,0 pays the seller in 

accordance with the terms and conditions of sale. The above-mentioned processes are 
carried out using the procedures described hereinabove. The system arranges for the product 
to be dispatched to the buyer and, together with invoice and shipping details optionally 
transmits to buyer a questionnaire asking buyer to comment about the bargaining or bidding 
1 5 experience and the service provided. 

Billing And Payment Embodiment 

Figures BP 1 -BP 10 describe an exemplary structure of the billing and payment system 
for the current invention. Buyers are billed for the product they have successfully bargained 
20 for and payment is made to the sellers in accordance with the conditions of sale. Buyer 
invoicing and seller payment is accomplished using conventional credit card electronic 
charges, checks, Electronic Fund Transfer (EFT), digital cash, or the like. These payment 
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methods are used herein for illustrative purposes, since there exist many equivalent payment 
methods, which are commonly known in the art and may also be used to practice the Internet 
bargaining method of the present invention. 

In Figure BP1, the billing process is initiated at step BP 1.1 when Business Controller 
5 2.0 transmits buyer response 1 .7 to the buyer that accepted the bargain price. The price and 
tracking number of buyer request 1.2 is sent to billing database 3.8 at step BP1.2. Several 
billing methods can be used. The first billing method is payment after delivery, in which the 
buyer pays before receiving the product. The second can be a credit system, in which the 
buyer pays at the end of the billing period. Special credit terms can be offered to 
10 corporations using the billing system for procurement of products or services. For example, 
the billing terms could be net 60 days or the like based on the credit worthiness of the 
company. 

In the payment after delivery method, billing processor generates a bill prior to 
dispatching the product to the buyer. It totals the amount owed by the buyer to the system at 

1 5 step BP1 .3 . For example, Business Controller 2.0 may require the buyer to prepay a token 
amount before the deal. The rest of the payment can be made after the product is received. 
Transaction records and balance information are stored in billing database 3.8. Money 
deposited with Business Controller 2.0 by each buyer is placed in an escrow account. Rather 
than actually depositing money with Business Controller 2.0 the buyer might instead be 

20 required to evidence the existence of sufficient credit to complete the purchase of the 

product or service. A credit card on file with Business Controller 2.0 or the payment terms / 
method is checked before bargain price acceptance notification/response is sent to the buyer. 
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Alternatively, a third party billing system or an outside vender that provides billing services 
can be employed by the Business Controller 2.0. 

If sufficient credit remains in the account then the billing process proceeds. If credit 
availablity is not sufficient to cover the total price, then the buyer is required to provide 
5 another credit or payment method acceptable to Business Controller 2.0. For Electronic 
Fund Transfers, the buyer's account information is stored in billing database 3.8 enabling 
Business Controller 2.0 to check the account balance before dispatching the product to the 
buyer. 

In a credit method the billing processor 2.3 searches billing database 3.8 by buyer ID 
1 0 at the end of each billing period and totals the amount owed by each buyer. At step BP 1 .4 
the preferred billing method is retrieved from buyer database 3.5 and the appropriate billing 
module (i.e. credit card, credit line, debit card, EFT, check, digital cash, electronic cash), is 
initiated at step BP 1.5. In an alternate embodiment, the buyer does not pay for the product 
unless buyer is satisfied with it. This embodiment allows the buyer to examine the product 
15 for a preselected time period before making payment. Upon being satisfied with the product, 
the buyer sends an authorization for payment to Business Controller 2.0. Alternatively, 
Business Controller 2.0 automatically initiates the payment process after the preselected time 
period unless notified by the buyer that the product is unsatisfactory. If the buyer is not 
satisfied, a rejection message is sent to the Business Controller 2.0 and a product review 
20 process is started as described hereinafter in the customer satisfaction embodiment. 

The process of paying the seller or vendor begins at step BP2.1 in Figure BP2. At 
this point, the price of the product and the tracking number of the seller request 1.4 are sent 
to payment database 3 .7. The ID of seller is extracted from product profile and stored in 
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payment database 3.7. At step BP2.2 payment processor 2.6 searches payment database 3.7 
by seller ID and totals the amount owed to the seller. Payment of the seller is effected in 
accordance with the conditions of sale and the mode of payment specified by the seller, 
which may contemplate payment after delivery, or by credit or the like. Payment after 
5 delivery is carried in accordance with the agreed upon terms and conditions of sale. The 
payment is transmitted to seller by the Business Controller 2.0 after receipt of payment from 
the buyer as per the terms and conditions of sale. In the credit method, the seller either 
establishes an account with the Business Controller 2.0 that maintains a balance for the seller 
or provides other alternatives, such as a credit card or an account with a third party to be 
10 credited. At step BP2.3, the preferred payment method is retrieved from seller database 3.6 
and the appropriate payment module is initiated at step BP2.4. This step may be held up until 
payment has been received from the buyer. 

Inasmuch as the buyers and sellers are not in direct contact, payment is made to 
Business Controller 2.0, in the case of the buyer, and received from Business Controller 2.0, 
15 in the case of the seller. The above methods describe a number of ways in which payment 
may flow from buyer to Business Controller 2.0 and from Business Controller 2.0 to seller. 
Set forth below are several methods by which Business Controller 2.0 may generate 
revenues for the provided services. 

In one embodiment a flat fee is charged for every successful bargain. This fee is 
20 charged to buyer in addition to the price of the purchased product and also to the seller on 
the sale of his product. There could also be a flat fee that would cover any number of 
transactions over a given period of time, allowing the buyers and sellers to subscribe to the 
service. In another embodiment Business Controller 2.0 can charge a premium over the final 
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bargain price of the product. This premium could be charged to either buyer or seller or 
both, once the deal is finalized. 

In one embodiment, advertisers pay to have messages included in buyer request, 
seller request or WebPages of Business Controller 2.0. Advertising revenues partially or 
5 fully offset the cost of delivering the product from seller to buyer in the most time efficient 
manner. Once the amount owed by the buyer has been calculated, appropriate billing 
methods are initiated. Figure BP3 illustrates an exemplary billing procedure using credit 
cards as a primary transaction tool. Simplicity is the advantage of this system. No bank 
account is necessary, and no paper transaction is required. 

10 In figure BP3, at step BP3.1, Business Controller 2.0 looks up the credit card number 

of buyer in buyer database 3.5. At step BP3.2, this credit card number is transmitted to 
billing processor 2.3. Billing processor 2.3 contacts the credit card clearinghouse to get an 
authorization number at step BP3.3. The billable amount appears on the credit card 
statement of the buyer at step BP3.4. Now this amount authorization is posted to the account 

15 of Business Controller 2.0 by the credit card clearinghouse at step BP3.5. At step BP3.6, 
Business Controller 2.0 updates billing database 3.8 to indicate that payment has been made 
or the Business Controller 2.0 uses a credit line billing procedure of the conventional type. 

A similar process occurs when the amount to be paid to the seller has been 
calculated. In Figure BP4, at step BP4.1, Business Controller 2.0 looks up the credit card 
20 number of the seller in seller database 3.6. At step BP4.2, this credit card number is 
transmitted to payment processor 2.6. Thereafter, at step BP4.3 the payment processor 
contacts the credit card company or clearing house, or issuing bank, to obtain authorization. 
The sale proceeds are credited to the seller's account at step BP4.4, where it shows up as 
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credit on his monthly bill or invoice. At step BP4.5, Business Controller 2.0 updates the 
payment database to indicate that payment has been made. At step BP4.6 Business 
Controller 2.0 transmits the notification of process completion to the seller. 

Figures BP5 and BP6 illustrate a payment procedure involving standard bank checks. 
5 In billing the buyer, Business Controller 2.0 looks up his mailing address at step BP5.1 in 
buyer database 3.5. This address is transmitted to billing processor 2.3 at step BP5.2. A bill 
is mailed to the buyer at step BP5.3, and the check is received from the buyer at step BP5.4. 
At step BP5.5, Business Controller 2.0 updates billing database 3.8 to indicate that payment 
has been made. Subsequently, in Figure BP6 at step BP6.1 , Business Controller 2.0 looks up 
10 the mailing address of the seller in seller database 3.6. This information is transmitted to 
payment processor 2.6 at step BP6.2. Payment processor 2.6 then automatically cuts a hard 
copy check, payable to the seller, which check is mailed to the seller at step BP6.3. At step 
BP6.4, Business Controller 2.0 updates payment database 3.7 to indicate the completion of 
process and keeps the record on file for inquiry purposes. 

1 5 Referring now to Figure BP7 and BP8, there is illustrated a procedure in which funds 

are transferred via ("EFT"). At step BP7.1 in Figure BP7, the bank account number of the 
buyer is accessed in buyer database 3.5. This account number is transmitted to billing 
processor 2.3 at step BP7.2, followed by the transfer of funds directly into the account of 
Business Controller 2.0 at step BP7.3. At step BP7.4, Business Controller 2.0 updates billing 

20 database 3 .8 to indicate that payment has been made. 

Paying the seller is essentially the reverse process. In Figure BP8, at step BP8.1, 
Business Controller 2.0 searches seller database 3.6 for the bank account number of the 
seller. This bank account number is transmitted to payment processor 2.6 at step BP8.2, 
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which transfers the money directly into the account of the seller at step BP8.3. At step 
BP8.4, payment database 3.7 is updated to indicate that payment has been made, and 
archives the record for inquiry purposes. 

In Figures BP9 and BP 10, there are shown commercial transaction procedures using 
5 digital cash. For billing the buyer, in figure BP9, Business Controller 2.0 accesses the buyer 
electronic delivery address in buyer database 2.0 at step BP9.1. This address is transmitted to 
billing processor 3.8 at step BP9.2. At step BP9.3, Business Controller 2.0 updates billing 
database 3.8 to indicate the payment at step BP9.4. Payment to the seller proceeds in the 
same way as in Figure BP9. 

10 After looking for the seller electronic delivery address in seller database 3.6 at step 

BP10.1, Business Controller 2.0 sends this address to payment processor 2.6 at step BP10.2. 
This address might be an email address if the digital cash is to be transferred by email, or it 
could be an IP address capable of accepting an online transfer of digital cash. At step 
BP 10. 3, the digital cash is downloaded to the seller and at the step BP 10.4, Business 

1 5 Controller 2.0 updates payment database 3.7 to indicate that payment has been made. 

Using these digital cash protocols, it is possible for the buyer to include payment 
along with buyer request 1 .2 in email form. A buyer that has bargained successfully with the 
Business Controller 2.0 can include digital cash along with buyer's confirmation that the 
product is satisfactory. 



20 
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Customer Satisfaction Embodiment 

Although the previous embodiments describe the delivery of product as the end of 
the process, it will be understood that the present invention allows for follow-up procedures 
to ensure that the buyer is satisfied with the product and services provided. These procedures 
5 include review of buyer comments by Business Controller 2.0 as well as periodic testing of 
the products offered for sale by a system assigned expert or by the Business Controller 2.0 
itself to verify product acceptability. The following figures describe these procedures. 

In Figure CS1 there is shown a customer satisfaction embodiment, the elements of 
which include buyer complaint reviewing and follow-up procedures. At step CS 1.1, the 

10 buyer sends comments concerning the product acceptability to the Business Controller 2.0. 
Business Controller 2.0 analyzes the comments against product standards and buyer's 
database at step CS1.2. At step CS1.3 the system checks whether the analysis of the product 
comments sent by the buyer indicates satisfaction. If satisfaction is indicated, then the buyer 
or vendor database is updated to indicate that buyer is satisfied with the product at step 

15 CS 1 .4. At step CS 1 .5, if the product comments are unsatisfactory at the step CS 1 .3 , then 
product database and seller databases are updated to indicate buyer's dissatisfaction with the 
product. A notice is issued to the vendor or seller containing advice concerning buyer's 
dissatisfaction with the product, at step CS1.6. Repeated notices based on buyer 
dissatisfaction with a product or service may result in temporary or permanent removal of a 

20 vendor or seller from the system database. 

Referring to Fig.CS2, there is illustrated the handling and processing of comments 
concerning buyer satisfaction with products received by the buyer. At step CS2.1, the 
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product is sent to the buyer. Thereafter, at step CS2.2, upon receiving the product buyer 
discovers that the product is unsatisfactory. This dissatisfaction of buyer could be 
attributable to several causes: (i) it could be caused by manufacturing defects, or (ii) the 
product does not conform with specifications contained in the buyer request, and the like. At 
5 step CS2.3, buyer returns the product to Business Controller 2.0, accompanied with a refund 
request based on the conditions of sale. The Business Controller 2.0 assigns an expert to 
analyze the validity of the buyer claim at step CS2.4. At step CS2.5, this assigned expert 
submits his report to Business Controller 2.0 after due investigation. At step CS2.6, Business 
Controller 2.0 checks the claim validity in the report. If the buyer claim is valid then 

10 Business Controller 2.0 refunds the money or replaces the product in accordance with the 
conditions of sale at step CS2.7 and updates all relevant databases. If, at step CS2.6, the 
claim is not valid then Business Controller 2.0 notifies the buyer about the denial or 
rejection of claim at step CS2.9 and updates its database at step CS2.10. Alternatively, the 
buyer may call the expert directly using a toll free number, to discuss and resolve issues 

1 5 concerning product dissatisfaction or offer comments and suggestions concerning the 
product or service. 

Having thus described the invention in rather Ml detail, it will be understood that 
such detail need not be strictly adhered to, but that additional changes and modifications may 
suggest themselves to one skilled in the art, all falling within the scope of the invention as 
20 defined by the subjoined claims. 
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